Securing and managing apps on a device using policy gates

ABSTRACT

A method of securing an app for execution on a device using an app security program with policy gates is described. First, Java class files are generated for the app security program, where the generating is dictated by a plurality of app security policies located in a plurality of policy gates. The plurality of policy gates are managed by a policy gate manager. Next, Java class files are replaced for the app with the Java class files for the app security program. Third, a security-wrapped app is created upon completion of replacing the Java class files for the app. Further, the security-wrapped app is prepared for execution on the device. Last, the security-wrapped app is re-signed with a new key.

CROSS-REFERENCE TO RELATED APPLICATIONS

This Application claims priority to U.S. Provisional Patent ApplicationNo. 61/985,202, filed on Apr. 28, 2014, the contents of which areincorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to software and mobile devices. Morespecifically, it relates to securing, governing, and managing apps ondevices, such as handsets, televisions, automobiles, and other emergingsmart device categories.

2. Description of the Related Art

As is now known in the computing and mobile handset and smartphoneindustries, a new computing paradigm is emerging and is being driven bythe proliferation of software applications now commonly known as appsfor handheld or mobile devices. This proliferation is directly tied toconsumer adoption of smartphones and tablets. Enterprises are nowcreating their own unique apps and distributing them to employees,customers, and partners. Companies are now writing their own apps fortheir employees and partners to use. However, with this growth anotherproblem is arising, namely, the security and management of these apps onhandset devices. Apps can cause significant damage to a handheld deviceand can cause loss of data or unintended transmission of data. They posevulnerabilities for the device and a security risk for the user.

Traditional anti-virus approach, such as provided by MyLookOut, does notremove damage done by an app on a handset device. While black listing ofapps is partially adequate for protecting devices (not only apps on thelist to be downloaded), it would be better if there was a method tocontain damage that a malware-infected app has done on a mobile device.It would be preferred if the kernel of the operating system software forthe mobile device did not have to be altered. It would also be preferredif the app author did not have to be trained in the art of secureprogramming, or write anything special or customized for security whenwriting the app—they should be able to simply continue writing apps asthey are currently doing.

SUMMARY OF THE INVENTION

In one aspect of the present invention, apps are secured orsecurity-wrapped either before they are downloaded onto a device, suchas a smartphone or tablet device, or after they are downloaded butbefore they are allowed to access the device operating system and causeany potential damage. An app provider, such as an employer or a wirelesscellphone provider, can secure its apps before consumers download an appfrom their app store, marketplace, and the like. The app is securedbefore it is allowed to access the operating system or other componentsof the device, thereby preventing the app from malicious behavior on thedevice.

In one aspect of the invention, a method of securing an app forexecution on a device using a security program is described. Core objectcode of the app is obtained and the digital signature is removed. Appobject code is substituted with security program object code, therebycreating a security-wrapped app. The security-wrapped app is preparedfor execution on the device and is re-signed with a new key. In thismanner a centralized policy to control and secure access to data isimplemented on the device.

In another aspect of the invention, a method of preventing an app fromdamaging a device is described. A security-wrapped app executes on thedevice. A security check by an app security program is applied to a callmade the app to the operating system of the device. Based on the resultsof the security check to the call, the app security program performs oneof the following: (a) allowing the call to pass to the operating system;(b) enhancing the call; (c) blocking the call; or (d) terminatingexecution of the security-wrapped app.

In another aspect of the invention, a method of securing an app forexecution on a device using an app security program with policy gates isdescribed. The method includes generating Java class files for the appsecurity program, where the generating is dictated by a plurality of appsecurity policies separate from the app security program and located ina plurality of policy gates. Each policy gate includes at least one appsecurity policy. The plurality of policy gates are managed by a policygate manager. The method further includes replacing Java class files forthe app with the Java class files for the app security program, wherethe Java class files for the app that are being replaced function as aproxy between the app and a device operating system. Next, the methodincludes creating a security-wrapped app upon completion of saidreplacing of Java class files for the app. In addition, the methodcontinues with preparing the security-wrapped app for execution on thedevice. Last, the method concludes with re-signing the security-wrappedapp with a new key.

In other aspects of the invention, a system and non-transitory computerreadable medium for implementing the methods described above arepresented.

BRIEF DESCRIPTION OF THE DRAWINGS

References are made to the accompanying drawings, which form a part ofthe description and in which are shown, by way of illustration, specificembodiments of the present invention:

FIG. 1A is a block diagram showing an overview of the app controlprocess of the present invention;

FIG. 1B is a block diagram showing an alternative embodiment of an appcontrol process of the present invention;

FIG. 2 is a block diagram showing components of an app security programin accordance with one embodiment of the present invention;

FIG. 3 is a flow diagram showing a process of making an app securebefore downloading it on to a device in accordance with one embodimentof the present invention;

FIG. 4 is a flow diagram of a method performed in policy manager inaccordance with one embodiment;

FIG. 5 is a flow diagram showing a process of a security-wrapped appexecuting on a handset or mobile device in accordance with oneembodiment;

FIG. 6 is a system architecture diagram of the app security controlsystem in accordance with one embodiment;

FIG. 7 is a block diagram illustrating an example of an app wrappingsecurity system implemented using policy gates or policy components inaccordance with one embodiment;

FIG. 8 is a flow diagram of a method securing an app for execution on adevice using an app security program using policy gates in accordanceone embodiment; and

FIGS. 9A and 9B are block diagrams of a computing system suitable forimplementing various embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Example embodiments of an application security process and system aredescribed. These examples and embodiments are provided solely to addcontext and aid in the understanding of the invention. Thus, it will beapparent to one skilled in the art that the present invention may bepracticed without some or all of the specific details described herein.In other instances, well-known concepts have not been described indetail in order to avoid unnecessarily obscuring the present invention.Other applications and examples are possible, such that the followingexamples, illustrations, and contexts should not be taken as definitiveor limiting either in scope or setting. Although these embodiments aredescribed in sufficient detail to enable one skilled in the art topractice the invention, these examples, illustrations, and contexts arenot limiting, and other embodiments may be used and changes may be madewithout departing from the spirit and scope of the invention.

Methods and system for preventing device software applications frominfecting or otherwise damaging a device, in particular, a mobiledevice, are described in the various figures. These types ofapplications, used often on a variety of mobile devices, such as smartphones, tablet computers, gaming devices, and portable computing devicesare commonly referred to as “apps.” These apps may also be downloaded onto non-mobile devices, such as TVs, computers, automobiles, and otheremerging smart device categories. Methods and systems described are notintended to be limited to operation on mobile devices. These deviceprograms or apps have proliferated and are now very prevalent.Currently, apps are typically written in either Java or C. The methodsand systems described herein may be applied to apps written in either orto apps written in other languages for different platforms. Most apps,if not all, have to communicate with the mobile device's operatingsystem to get a specific service that the app needs in order to performits intended function and this service is usually only available fromthe operating system. A common example of such a service used is GPS toget the location of the device which the app may need. However, becauseof this exposure, apps are a vulnerability for the device and pose asecurity and privacy risk for the user. Companies want to be ableenforce a centralized policy to control and secure access to its dataand software. This is also true for end users (i.e., individuals, homeusers, and the like). It enables enterprise IT departments to maintaingovernance of corporate data. The methods described below provide acentralized way to control security with respect to apps that aredownloaded onto mobile devices, where the devices are either anemployee's personal phone or an employer's phone, so that those apps donot pose a security threat. Various embodiments of the invention mayalso be used by parents and individuals (i.e., in home or non-workenvironments) to ensure that their personal mobile devices are safe frommalware and may also be used to apply controls, such as on usage.Embodiments of the app control software of the present invention mayalso be used for mobile device data protection and back-up and forapplication-level telemetry.

FIG. 1A is a block diagram showing an overview of the app controlprocess of the present invention. It is a generic description of oneprocess without being tied to a specific configuration or environment.An app 102 is provided by app provider 100 which can be any type ofentity (individual, software developer, employer, etc.). It is generallyunprotected and the only security surrounding it is provided by theoperating system. The only shield and checking done on how it executeson the device once loaded is provided by the operating system.

The present invention enables additional security of the apps that isnot provided by the device's operating system. A security applicationprogram 104 is applied to app 102. Or the app 102 is input to program104, which may be supplied by a third-party app security provider. Inone embodiment, security application program 104 has a policy managerand a policy wrapper which may be in different locations. They aredescribed in greater detail in FIG. 2. Once security program 104 hasbeen applied to app 102, the app is wrapped with a security layer sothat the device is protected. It is shown as secured app 106. In oneembodiment, secured app 106 is then downloaded onto a mobile device 108,such as a smart phone or tablet computer, where it executes securelywithout risking damage to device 108. Another benefit is that securedapp 106 may also be managed by the company or other entity that isproviding the app to the user, such as an employer providing the app toan employee. For example, if the user leaves the company, the companymay automatically delete the app and any related data from the device.In another example, a parent may be able to limit the apps used byanother person (e.g., a child) or to limit the amount of time, e.g., 10minutes a day or limit which Web sites may be accessed by an app. Or, aparent is concerned that an app is leaking a child's location to unknownthird parties. There may be numerous other examples. As noted, FIG. 1Ais intended to show the general process of securing an app anddownloading it onto a device. Note that in this embodiment, app 102 isnot made secure from causing harm to the device after it is downloadedonto the device, but before. In another embodiment, the app is securedafter it is downloaded onto the device, but before it can interact withthe operating system.

FIG. 1B is a block diagram showing an alternative embodiment. Anunsecured app 110 (also supplied by an app provider) is downloaded ontomobile device 112. In this embodiment, however, there may be a speciallydesigned app on device 112 that blocks the actual installation ofunsecured app 110. The special app (not shown) redirects unsecured app110 to an app security program 114. The unsecured app 110 is wrapped ina security policy, the resulting app shown as secured app 116. It isthen downloaded and allowed to be installed on device 112 by the specialapp. In this manner, an individual or home user, for example, who wantsto protect her phone from security threats posed by apps, can have appsmade secure (wrapped) by a third-party service or by her mobile phonecarrier, to mention only two examples, before they are downloaded on toher phone. It should be noted that this security wrapping can be done toan app regardless of where the user downloads the app from. It may alsobe noted that in FIGS. 1A and 1B, the network and connections betweenthe components and software are shown generically. The transmissions areprimarily over the Internet (not shown) but may also be within a privatenetwork or both.

FIG. 2 is a block diagram showing components of an app security programin accordance with one embodiment of the present invention. In oneembodiment, the security program has two major components, a policymanager and a policy wrapper. A policy manager 202 accepts input from anadministrator or other individual who is responsible for settingsecurity for the mobile device. The person may be referred to as thegovernor since he is governing the security of the one or more mobiledevices. The security policy may be set using various user interfacescreens. There are numerous examples of policies, including geo-fencing(e.g., the app can only be used in a building) and others. The serviceprovider or the entity providing the app security program may alsoprovide default policy and security settings which may be useful forhome users. Examples of policy settings are described below. Policyinput 204 is inputted into policy manager 202. Policy manager 202 takesthe input/settings from the governor and creates policies or meta-data206. The format or form of meta-data 206 can vary. They essentiallyreflect the policy settings from the governor.

Metadata (policies) 206 may be used as input to a policy wrapper 208. Inone embodiment, this component of the program takes the policies anduses them to secure an app 210 by wrapping it. Wrapper 208 receives anapp 210 from a handheld device 212. In one embodiment, wrapper 208receives a copy of an app 210 instead of the original app 214 that wasdownloaded onto phone 212 (see FIG. 1B above). Here the handheld device212 user attempts to download an unsecured app 216 from an app provider218. In the scenario in described in FIG. 1A, it may operate on the appitself instead of a copy. This may be the case where a market place orapp store offers customers a secured version of the app along with anunsecured version (or only offer the secured version). A secured version220 (security-wrapped version) is returned from policy wrapper 208 todevice 212.

Metadata 206 may also be used to update a local policy file (an existingpolicy that is already on the device). A local policy file is used toupdate policy parameters residing on device 212. For example, in thecase of “geofencing” (i.e., restricting use of an app to an certainphysical areas) it is likely that the GPS locations controlled by thegovernor will change over time. When such a change occurs, the newpolicies can be applied in two different ways. One is to generate a newpolicy and apply it to the original app (i.e., wrap the app with the newpolicy). Another way is to allow dynamic configuration based on a localpolicy data file with the “variable” part of the policy encrypted/signedinside it. For example, an IT person may want the ability to override aconfiguration on a device directly through an IT app residing on thedevice for diagnostic purposes.

In one embodiment policies have two components: a fixed part and avariable part. The fixed part is the content described in the policyfile (e.g., “protect the GPS at certain times of day”). The variablepart typically is provided by the governor through a console (e.g. “whatare the times when the GPS should be protected?”). The variable part canchange without applying a new policy.

Policy designers can choose to forego the variable component of thepolicy and basically “embed” all data or content statically in thepolicy file. In this case, the console does not have any way tocustomize the policy.

If the policy designer chooses to include some variable component in thepolicy, when changes are made to the variable data (on the console), anew data file could be sent to the device to reflect the latest changes.Such a file would be encrypted/signed (to prevent a malicious appcircumventing the policy), downloaded to the device, and used by the appsecurity code on the device to apply the new data to the appropriatepolicy.

Such changes and updates may be done by local policy update component222 at runtime. This component creates updated policy parameters ondevice 212. Thereafter, wrapped app 220 will use the updated policyparameters.

In one embodiment, policy manager 202 and policy wrapper 208 arecomponents in the same app security program and may operate on the samecomputer. In other embodiments, the manager and wrapper components maybe on separate computers. For example, the policy manager 202 may be ona server at one site and the policy wrapper 208 may be on a computer atanother site and may be managed by a different entity or the sameentity. Collectively the manager and wrapper form the app securityprogram which, in one embodiment, is operated by a security serviceprovider. It may also be provided by an enterprise, such as a company,employer, business partner, and the like, or by a mobile phone carrier.

FIG. 3 is a flow diagram showing a process of making an app securebefore downloading it on to a device in accordance with one embodimentof the present invention. At step 302 a copy or clone of the app that isto be secured is made on the device. In one embodiment, this may be doneon the mobile device itself or may be done off the device, for example,on components on the Internet, in the cloud, on an enterprise's serveror on a carrier server. The user may be an individual, an employee of acompany or other entity. As is known in the field, an app may beobtained in a number of ways, most typically from an app store or an appmarket, or directly from the app developer or provider or in anysuitable manner. By making a copy, the original app is preserved givingthe user an option to use either the secured or unsecured version andalso protects the user's ability to use the app if something goes wrongwith the app control process. Note that in one embodiment, the app isnot yet downloaded on to the phone. In one embodiment, the methodsdescribed below are performed on separate computing devices. In anotherembodiment, the process may be performed on a mobile device, but the appis only executed on the device after the process is complete and the apphas been made secure.

At step 304 the app is decapsulated. Most, if not all, apps have digitalsignatures signed by the author/developer. At step 304, as part of thedecapsulation, the digital signature is removed from the app. This maybe done using techniques known in the art. Decrypting the app may alsobe performed at this step. These and other steps provide the core objectcode of the app which may now be operated on by the app control program.The nature and specifics of this operation may depend on the mobiledevice's operating system.

There are several examples of operating systems for smart phones such asiOS (for the iPhone), Android (used on handsets from variousmanufacturers), Windows Mobile 7, Web O/S, Palm, and others. At step306, the core object code app may be either disassembled or decompiledto obtain the executable object code. For example, it can be either“native code” (CPU instructions) or bytecode (virtual machineinstructions, such as Java or .Net). In one embodiment, this may be moreof a modification process if the device runs iOS where the disassemblyis closer to a process of locating and substituting certain links andterms. However, in general, the disassembly process to obtain the objectcode of an app after it has been decapsulated may be done usingtechniques known in the art, such as using disassemblers.

At step 308 the app object code is augmented with object code from theapp security program. For example, this object code may include classfiles which are replaced with class files from the security program. Theobject code generally provides an interface to the mobile deviceoperating system. The app control security program object code isderived, in part, from the policy/meta-data described above. In the caseof iOS, the operation is different in that a ‘locate and substitute’process occurs rather than an object code replacement. This takes intoconsideration an interrupt approach that iOS's uses. Generally, the appsecurity program goes through the assembly language code. The specificitems located are Software Interrupts (SWIs) within the object code andwhich are replaced with a branch to an app control security programlayer which may then determine what further actions to take, such asmaking the request, enhancing the results, and others, as describedbelow.

At step 310, after substitution of the object code (or substitutions ofSWIs) has been made, the app security program prepares the securitywrapped app for execution on the mobile device. The object codesubstituted into the app by the security program generally provides abridge or connection between the app and the mobile device operatingsystem. The security program class files may be described as wrappingaround the operating system class files. The app security program classfiles are generated based on the policies created earlier (by input fromthe governor). The app is essentially re-wired for execution on thehandset. It is re-wired to use the app security program layer inaddition to the security provided by the mobile device operating systemlayer. That is, the secured app may still be subject to the securityprovisions of the operating system. In one embodiment, certain cosmeticchanges may also be made to the app, such as changing the icon for theapp to reflect that it is secured. By doing this, the user can be surethat when the app icon appears on the handset screen that the securedversion of the app will be executed. The app has now essentially beenre-factored or re-programmed by the security program.

At step 312 the app is signed with a new key, for example, with the keyof the service provider or the key of the enterprise providing thesecured app. The re-factored, secured version of the app is returned tothe handset device. In another embodiment, the app is wrapped with thesecurity layer on the phone. At step 314, in one embodiment, theoriginal, unsecured copy of the app is deleted from the handset device.This may be done by the secured version of the app once it is downloadedonto the handset. In other embodiments, this is not done and bothversions remain on the mobile device. At this stage the process iscomplete.

FIG. 4 is a flow diagram of a method performed in policy manager 202 inaccordance with one embodiment. At step 402 the governor or othersecurity policy individual is enabled to define, generate, and createsecurity policies. This may be a network administrator for an enterprisedeciding a vast array of mobile device security policies for hundreds ofemployees using dozens of enterprise apps (specifically for work) thatmay be downloaded on hundreds or thousands of mobile devices. On theother end of the spectrum, it may be a parent who is setting securitypolicy for three or four apps downloaded by her child on a new mobiledevice. Other examples include preventing or squashing a gaming appusing GPS, preventing an app from using a microphone on the device torecord or eavesdrop on a conversation, among many others. In eithercase, the governor may take into consideration the category of the app,the type and nature of app, the author, the age-appropriateness, andnumerous other factors. For example, has the same author written anyother apps that may have been classified as malware or posed a securitythreat to the device. It may determine whether there are other apps bythe same author. It is at this stage that the governor decides whichrules to apply for each app. In one embodiment, this is done off-line bythe governor. That is, it may be done using user interfaces on a homecomputer or on an enterprise network computer used by an administratorwhere security templates provided by the security program serviceprovider (essentially default templates) may be used or very specificrules may be set using the templates.

At step 404 the security data input at step 402 is used by the appcontrol security program to create the actual policies. At step 406 theapp control security program object code is generated based on the inputfrom the governor regarding security policies created at step 404. Thegovernor or service provider may also update existing security policiesif needed. As described above, the object code may be used to enhancecertain original object code obtained from the disassembled app. Theenhancement code is inserted to adjust security and privacy settings foran app in order to protect the enterprise and end user. The originalapp's behavior is altered which allows the governor to control how theapp behaves. For example, if an app stores sensitive account informationin the clear (i.e., un-encrypted), the behavior could be changed so thatall information the app creates is stored in encrypted form and whichcan only be accessed by that app given that the key to the stored,persistent data would be unique to the app. In many instances theenhancement code can improve the apps performance since the code isoptimized for a particular use scenario.

FIG. 5 is a flow diagram showing a process of a security-wrapped appexecuting on a handset or mobile device in accordance with oneembodiment. At step 502 the behavior of the app when the app executes orimmediately before it executes on the device is altered or modified. Forexample, behavior modification may include authentication during appinitialization; e.g. smart/CAC card, or password challenge. Some apps,as originally designed, may not require a password for security,however, a secured version of an app which has been modified may requirethat the user enter a password. At step 504 the secured app executes onthe mobile device by the user activating it (e.g., tapping on the iconif the device has a touch screen). Upon execution of the app, in oneembodiment, control can take one of four options. As is known in theart, when an app executes, it makes calls or requests to the deviceoperating system in order to carry out its functions. In many casesthese calls may be harmless or pose no significant security threat tothe phone or device. If this is the case, the call may be allowed topass to the operating system as shown in step 506. Here the call is madeto the device operating system and the app executes in a normal manner.

If the security layer or wrapper around the app detects that the app ismaking a request that may pose a security threat to the device, the appsecurity layer may enhance or modify the request before it is passed tothe operating system or other software or hardware component in thephone. This is shown at step 508. In one embodiment, the governordetermines which calls are permissible by examining the one or morepolicies. For example, the governor may determine that all data shouldbe saved in encrypted form. In another example, the governor may decidethat only a select group of trusted apps should have data on a soldier'sGPS coordinate. In one embodiment, there is no runtime logic todetermine what is safe, a potential threat, or an actual threat; it isessentially pre-declared by the governor in the policy created at step404 above. In another embodiment, there may be some runtime logic. Forexample, an app may be trying to send out expensive SMS text messages.The app control program may determine this and block the app fromsending more than a certain number of text messages, for example, it maylimit it to transmission of one message. The enhancement may be addingsomething new, such as a password requirement. In another example, ifthe call is to save data on the mobile device memory, the secured appmay actually back up the data to a storage area in the cloud or on theInternet (i.e., off the device). In another example, the data related tothe call may be encrypted.

At step 510 the secured app may determine that the call is an actualthreat and should be dealt with in a more severe manner than at step508. For example, it may have decided that based on the policy for anapp, that if a camera on the device is accessed while in a securebuilding (e.g., the Pentagon), the app should immediately be terminated.Merely enhancing the request may not be sufficient in this case. At step510, the request may not be allowed to proceed to the operating systemor any other component of the device. However, in one embodiment, aresponse is returned to the app, but that response is intentionally notaccurate or correct. It is essentially an obfuscated response. Forexample, it may be a GPS coordinate that is not the actual physicalcoordinate of the device (e.g., the device is in California, but the GPScoordinate that is returned to the app is a coordinate in Nebraska).This may be desirable when apps are used by children. Other examples maybe returning bad or garbled data results if an app that should only runwithin a restrictive environment (e.g., a secure office area) isdetermined to be running outside that environment (e.g., at home). Inthis example, the app may be partially crippled so that the app can onlyaccess unclassified data and wherein classified information isnullified. In another example, when a user is attempting to paste orcopy sensitive data from a classified app to a non-classified app, theapp control program may change the copy of the data that is being pastedto garbage or essentially make it meaningless. After either steps 506,508, or 510 have completed, the security-wrapped app continues executionon the mobile device at step 514.

At step 512 the security layer around the app has determined that thecall being made by the app or that the app execution behavior in generalposes too high a security threat level to the mobile device. In thisextreme case, the security layer decides to terminate execution of theapp and/or delete the app. For example, the app may be using too manyresources on the phone, such as bandwidth, or is making too manyhigh-risk calls to the operating system thereby over-exposing the mobiledevice. In this case, the app can simply be deleted from the phone orthe app may be terminated. The user may not be able to re-execute it orre-install it. For example, an employee may not install that app againon the company phone because it was exposing sensitive company data. Orit may be determined that an app is secretly collecting data on thephone or installing malware.

FIG. 6 is a system architecture diagram of the app security controlsystem in accordance with one embodiment. A trigger manager component602 handles two events, one for generating a new policy 604 and anotherfor updating policy parameters 606. Such events can be triggered byvarious systems. For example, a console administrator or governor mightapply a new policy to all devices (a manual operation). Or a networkmonitoring application, after detecting suspicious traffic originatingfrom a device (or app), could push a new policy that would prevent auser/device/app from accessing network resources (an example of anautomated operation). The various systems or entities that have theauthority to change/update polices, do so through the trigger manager602.

New policy output 604 is input to a policy definition file 608 which maybe generated at runtime and may include various types of code andextensions, for example, specific to the app control service provider,or to the app/user/device the policy applies to. Policy definition file608 is input to a policy compiler 610 which has two outputs. One outputis a wrapper definition file 612. This file is input to an app wrappercomponent 614. App wrapper component 614 is responsible for generatingsecure app by injecting custom binary code (native or bytecode) into anapp, downloaded directly, for example, from an app store. Or the appcould be an app the user downloaded on to his device, and then uploadedto an “AppControl” server.

App wrapper component 614 may have three inputs: apps from one or moreapp stores 616, certificate key management data from identity managementcomponent 618, and hardened components 620. Key management data is usedto tie the identities of the user, device, and the app, and ensure thatany operation subject to policy control can be tied to a specificuser/device/app. This also ensures that a wrapped application can onlybe run on a specific device to prevent a malicious app fromcircumventing policies and hardened components 620 (for example “Devicesecurity framework”). The output from app wrapper 614 is a wrapped app622 which is downloaded or installed onto mobile device 624 via thedevice's controller 626. Device controller 626 responsibilities include:download app from the app wrapper; ensure that app running on thedevices are appropriately wrapped apps (e.g., app wrapped for user1should not be installed/run on device for user2); report list/version ofinstalled applications to allow the management console to controlpolicies for each device/user/application; and download policyparameters when appropriate. Wrapped app 622 resides on device 624coupled with policy parameters 628.

Returning now to policy compiler 610, the other output is a runtimepolicy definition file 630. This file is input to a runtime policycompiler 632 which also accepts as input policy parameters 606(specified by the management console, or other subsystems). Output fromcompiler 632 is a device runtime policy file 634. This file 634 isdownloaded onto device 624 as shown as policy parameters 628, and isused to customize the policies applied to wrapped app 622.

Described below are various use cases and capabilities of the appcontrol security program of the present invention. One use case involvesthe separation of work life and personal life on a mobile phone. Thereare apps for the user's personal use and apps that the user's employer(or a business partner of the employer) may have provided and the appsoperate on the same phone, which is often the user's personal phone. Thegovernor who determines security of the apps that need to be secured onthe user's phone may block copy/paste operations between apps (such ase-mail apps). The governor may set policies for the work-related appsthat perform selective wipes of apps and associated files. Userlocation-based policies may also control where certain apps may execute.Examples of levels of protection because of malware are denying accessto contacts, denying transmission of SMS without consent, and the like.

Another example of a use case is app control. Using the presentinvention, white and black listing of apps may be implemented, as wellas full deletion of apps according to the policies set by a governor. Anapp may be ‘sandboxed’ to protect the other apps, software, and hardwareof the device. Other capabilities may include identity-based control ofapps or services and highly granular control over app behavior. Trojanidentification is another use case that can be implemented with the appsecurity program. For example, each app and content may be encrypted toprevent rogue apps from gaining access to and stealing confidential dataon the phone. The security program may also be able to identifyanomalous system call behavior of an app to identify malicious Trojanapps that act outside of their published intent.

Another use case is back-up and recovery of app data in which ITsecurity administrators and governors have data revision control and canimplement app and device content migration through back-up and restoreoperations. In another use case is network traffic monitoring. The appon the mobile device may be brought under the visibility of existingenterprise IDS/IPS/Web filtering infrastructure to allow for inspectionand control of app communications. The app security program can alsointegrate with third-party DNS services, such as Symantec's DNS serviceto identify malware. All app communications may be encrypted, includingcommunications at the mobile phone service provider. Other use casesinclude session continuity, consumer privacy (e.g., GPS obfuscation,implementing safe DNSs), and intercepting payment/transaction messagesfrom the mobile device (i.e., operating in the middle of mobile commercestreams).

In one embodiment, the app security service is offered by a third-partyservice provider, for example, to make apps used by end-users orindividuals (i.e., users not associated with an employer or enterprise).For example, a parent may want to obfuscate the GPS of a child's phonebecause the parent does not want a social network site, such asFacebook, to know where the child is, essentially disabling GPS. Inanother embodiment, an app store, operated by a wireless phone carrier(e.g., Verizon, AT&T) may offer a secured app for an extra charge orpremium. A customer of the carrier can download the secured app from themarketplace or online store instead of the unsecured version by payingan extra amount. In another embodiment, an enterprise may have its ownapp store for its employees, partners, and the like, where users canonly download secured versions of the apps (which may be referred to as“hard” apps). These apps may have many of the security featuresdescribed above as defined by a governor (security administrator) at theenterprise, such as blocking copying and pasting e-mail or corporatedata, killing an app from the user's phone if the user leaves thecompany, and so on. A mobile phone carrier's DNS can typically accessany site, but the app security program can block a mobile device browserso that it can access only a safe DNS (e.g., Symantec's DNS) from whereonly safe Web sites may be accessed. In another embodiment, the appsecurity program provider can work with the mobile device manufacturerto incorporate the app security program or functionality into thehardware and software operations of the device. In this embodiment,described below, a user can download an unsecured app and make issecured on the phone or device itself before executing and does not haveto access a third-party service to have the app secured or ensure thatthe app is secured before being downloaded onto the device.

As can be seen from various embodiments described above, the security ofthe mobile device extends beyond the device itself and is applieddirectly to the apps that are downloaded onto the device. Companies andother entities are able to take advantage of apps more freely withouthaving to worry about the security risks, such as data leakage ormalware infection of the company's enterprise IT system. Companies canmaintain governance of its corporate data.

In one aspect of the present invention, policies can be grouped orcategorized in policy gates which facilitate app development,specifically, for app developers to write policies and have themimplemented when an app executes. In some embodiments, when a new policyis introduced to the app wrapping software, the policy has to behard-coded into the wrapping software. The software provider presentlyhas to hard code the new policy into the app wrapping program that theprovider sells, for example, to enterprises. In these embodiments, thisrequires a change to the main control flow and possibly to othersegments in the app wrapping software. It is not unusual for this typeof change or update to the main control flow to cause issues in thewrapping software such as unexpected side effects, unpredictablebehavior, or errors and bugs. Such a change will likely also requirere-testing of the app wrapping software program. In some embodiments,having to manually insert a policy into the wrapping program isgenerally undesirable because it makes the program code more brittle,more prone to unexpected execution, and more error prone.

In one aspect of the present invention, policies are conceptualized intogeneric categories or sets referred to herein as policy gates. By usingpolicy gates, policies do not need to be hard-coded into the appwrapping software. When a new policy is written, either by the appwrapping software provider or by an enterprise using the app wrappingsoftware, the new policy is put in an existing policy gate or a newpolicy gate is created for the new policy if the policy does notlogically fit into the existing policy gates. In some embodiments, anynew policy gates created are inserted into a policy gate list,maintained by a policy gate manager (not to be confused with the policymanager in the app wrapping software as described earlier in theapplication). In one embodiment, each new policy is stored in anexisting or new policy gate. In various embodiments, the details andspecifics regarding each policy are removed from the app wrapping codeand put in a portable component called the policy gate. This makes itpossible for an enterprise or other customer of the app wrappingsoftware provider to write their own policies and have these policiesinjected into the app at runtime. It also allows them to implement newpolicies and to not have to change the code or the main control flow ofthe app wrapping software itself.

The following is an example implementation of an app wrapping securityprogram using policy gates as implemented on an Android device. When anAndroid app begins execution, a series of checkpoints occur in theoperating system. This is also true in iOS. The operatingsystem/platform provides certain “hooks” to the app. These hooks informthe app of which part of the app execution life cycle the app is in. Forexample, one checkpoint is initializing or setting up the app. In suchan example, the operating system, through the policy gate manager, tellsthe app that the app is starting up and asks the app: “What would youlike to do now?” The app then checks to see what its default settingsare in response. In another example, the hook or lifecycle state of theapp may be the event “go to background.” As with the initializationexample, the operating system asks the app what it would like to do nowthat it is in a particular state or checkpoint in the life cycle. Onceagain, the app decides what to do, and in making this decision looks atits default settings. In addition, the app may use the services of theoperating system, for example, location services, in response to theinquiry by the operating. In various embodiments, the app will want toknow “Where am I now in the life cycle?” in order to make theappropriate function calls, such as to a network or to the operatingsystem.

In some embodiments, policy gates are implemented in a mobile deviceoperating under Android. When the app executes, the policy is injectedinto the app during runtime. When the app is started, a policy gatemanager goes through each policy gate (using a policy gate list) which,in one embodiment, implements a new policy. The policy gate manager goesdown the list of policy gates. In some embodiments, the policy gatemanager is the module that tells the app which checkpoint the app is in(e.g., the app is initializing) and tells the app “proceed with doingwhat is needed to execute normally.” For example, the app may display inlandscape, portrait, or full-screen mode. In other examples, the app mayneed to call the operating system for services, such as locationservices or accessing secure data storage.

In some embodiments, there is a customized policy gate having a customUI that the policy gate manager is able to interpret. At any given timein the app life cycle, each policy gate is aware of which stage the appis in. As noted, a policy gate manager goes to each policy gate and letseach one know which checkpoint has passed and, if needed, to call theappropriate function(s) (e.g., if the checkpoint is initialization, thenthe policy gates can each call an initialization function, if needed).Not every policy gate may have a function to call for each checkpoint inthe app's lifecycle. If there is a function to call, each policy gatewill execute that function and proceed. For example, each policy gatewill initialize itself (assuming each policy gate has an initializationfunction to call).

As noted, the policy gate manager goes to each policy gate at the timeof each checkpoint in the app's lifecycle. Another example of acheckpoint may be when an app goes to background (is no longer shown onthe device screen). At this checkpoint, a policy gate may have afunction it needs to call in order to adjust the display of the app. Asnoted above, the policy gate manager is the module between the policygate and the wrapped app. The policy gate manager makes a function callto a policy gate. The policy gate manager also controls what the usercan or cannot do at any particular time. For example, it can block useractivity on the app.

In some embodiments, each policy gate has one policy. In otherembodiments, policies can be grouped into categories (or buckets), witheach category of policies being under one policy gate. In someembodiments, a policy gate can tell the policy gate manager (operatingbetween the policy gate and the app) to prevent a user from using an appduring a certain period. The policy gate manager makes function calls tothe operating system and provides services and context to the policygates (examples, as noted above, location services, current state of appwrapping program, access to secure data storage, etc.). With respect togrouping policies, certain policies share an underlying commonality thatmakes them prone to being grouped into families. A few examples includeauthentication related policies (e.g., policies that use VPN, biometric,passphrases, and the like), data leakage prevention-related polices(e.g., copy/paste, email/SMS/camera/social media enforcement, and thelike), and location policies (e.g., geo-fencing policies). A category ofpolicies contains policies that use the same or similar services fromthe operating system, that is, have a set of common services. Forexample, if there is a new authentication policy (e.g., an employee hasto have a fingerprint scan in order to use an app) that an enterprisewants to use with the app wrapping software, the enterprise appdevelopers could get the base authentication policy code/implementationfrom the appropriate policy gate and then add/create the specificfingerprint scanning code. In such embodiments, the app developers wouldnot have to write the whole fingerprint scanning authentication policyfrom scratch and have it hard-coded into the app wrapping software. Theapp developers could use a base authentication code, such as the codefor managing the keystore, and not have to re-write code for the policythat is substantially common with other authentication policies. In someembodiments, each category is represented by one policy gate. In otherembodiments, a category can be represented by multiple policy gates.

The following is an example implementation of an app wrapping securityprogram using policy gates as implemented on an iOS device. In someembodiments, the concept of policy gates may be implemented in an iOSenvironment.

FIG. 7 is a block diagram illustrating an example of an app wrappingsecurity system implemented using policy gates or policy components inaccordance with one embodiment. In this particular example, the systemruns in an iOS environment. However, as described above, in someembodiments, an analogous system running in an Android environment canalso be implemented using analogous principles and features to thosepresented in FIG. 7. A component, referred to as MapAppDelegate 702, isa core delegator of events in the policy gate implementation.MappAppDelegate 702 also receives calls from the operating system (iOS)of the device. MappAppDelegate 702 has functionality similar to the maincontrol flow code in an app wrapping security program in the Androidexample. In some implementations, in an iOS device, “events” in an applifecycle represent checkpoints in the app lifecycle. These eventsinclude “become active,” “backgrounded,” “foregrounded,” “terminated,”“display UI,” “dismiss UI,” and “app launched.” In some embodiments,MapAppDelegate 702 captures these and other events in the app lifecycle.Presently, in some embodiments, all policies are launched fromMapAppDelegate 702. As such, it experiences the same issues as the maincontrol flow in the Android example. For example, such embodiments canget cluttered and unwieldy. It becomes difficult to manage and updatepolicies without causing errors and unwanted or unexpected side effectsto the operation of the MappAppDelegate 702. Furthermore, from a programdesign perspective, adding and launching all policies fromMapAppDelegate 702 does not take advantage of object oriented designprinciples which would make the code more efficient, easier to manage,and elegant.

In some embodiments, there is a policy engine that is in communicationwith the MappAppDelegate 702. In the particular example shown in FIG. 7,MappAppDelegate 702 has a policy engine 704 with which it communicates.Specifically, MappAppDelegate 702 sends notifications to the policyengine 704 whenever an event (appLaunched, appBackgrounded, etc.) occursin the app lifecycle. In some embodiments, policy engine 704 may bedescribed as a container for all policies. In some embodiments, policyengine 704 has analogous function to the policy gate manager aspreviously described. In some embodiments, MappAppDelegate 702 does nothave to include any existing or new policies. In some embodiments,policy engine 704 has one or more policy components 706. In someembodiments, policy components 706 have analogous functions to policygates, as described above. In FIG. 7, Policy engine 704 in turn notifiesmultiple (one or more) policy components 706 of each event at eachevent. In some embodiments, a policy component 706 contains a policyabstract class, similar to the categories mentioned above. All policieswithin a policy component 706 conform to a certain behaviorrepresentative of the policy abstract class and inherit from policycomponent 706, policies of a certain category in a policy gate in theAndroid example. In some implementations, each policy component 706contains a policy protocol 708. Each policy protocol 708 is the same foreach policy abstract class in a policy component 706. Each policyabstract class may be specific to a particular category of policies asdescribed above, such as authentication, location services, data leakageprevention, and the like. In some embodiments, a policy abstract classin a policy component 706 is notified by policy engine 704 when applifecycle events occur that would normally be handled by theMapAppDelegate 702. In some embodiments, certain policy components 706include a dynamic view controller 710 that can be used for flexiblemonitoring and management. The block diagram in FIG. 7 represents oneexample of a system and method for implementing an app wrapping securityprogram that also allows for extensible policy creation.

FIG. 8 is a flow diagram of a method 800 for securing an app forexecution on a device using an app security program using policy gatesin accordance with one embodiment. Method 800 begins with generating(802) Java class files for the app security program. In someembodiments, generating the Java class files is dictated (804) by aplurality of app security policies. In some embodiments, the appsecurity policies are separate (806) from the app security program andlocated (808) in a plurality of policy gates. Each policy gate includes(810) at least one app security policy. In some embodiments, theplurality of policy gates is managed (812) by a policy gate manager.

Next, method 800 includes replacing (814) Java class files for the appwith the Java class files for the app security program. In someembodiments, the Java class files for the app that are being replacedfunction (816) as a proxy between the app and a device operating system.Next, method 800 includes creating (818) a security-wrapped app uponcompletion of said replacing of Java class files for the app. Thesecurity-wrapped app is then prepared (820) for execution on the device.Last, method 800 concludes with re-signing (822) the security-wrappedapp with a new key.

In some embodiments, a new app security policy is added to an existingpolicy gate in the plurality of policy gates. In other embodiments, anew policy gate is added to the plurality of policy gates in order tostore a new app security policy. In some embodiments, the app securitypolicies are not hard-coded in the app security program such that theapp security program does not include details and specifics regardingany app security policy. In some embodiments, each app security policyin a policy gate includes an underlying commonality with all other appsecurity policies in the same policy gate. In some embodiments, thepolicy gate manager goes, during execution of the security-wrapped appon the device, to each policy gate and lets each policy gate know inwhich checkpoint or event in an execution life cycle thesecurity-wrapped app is in. In some embodiments, a policy gate calls anappropriate function in response to being notified by the policy gatemanager of a certain checkpoint or event in the execution life cycle ofthe security-wrapped app.

Each of the operations shown in FIG. 8 may correspond to instructionsstored in a computer memory or computer readable storage medium. Thecomputer readable storage medium may include a magnetic or optical diskstorage device, solid state storage devices such as Flash memory, orother non-volatile memory device or devices. The computer readableinstructions stored on the computer readable storage medium are insource code, assembly language code, object code, or other instructionformat that is interpreted by one or more processors.

FIGS. 9A and 9B illustrate a computing system 900 suitable forimplementing embodiments of the present invention. FIG. 9A shows onepossible physical form of the computing system. Of course, the computingsystem may have many physical forms including an integrated circuit, aprinted circuit board, a small handheld device (such as a mobiletelephone, handset or PDA), a personal computer or a super computer.Computing system 900 includes a monitor 902, a display 904, a housing906, a disk drive 908, a keyboard 910 and a mouse 912. Disk 914 is acomputer-readable medium used to transfer data to and from computersystem 900.

FIG. 9B is an example of a block diagram for computing system 900.Attached to system bus 920 are a wide variety of subsystems.Processor(s) 922 (also referred to as central processing units, or CPUs)are coupled to storage devices including memory 924. Memory 924 includesrandom access memory (RAM) and read-only memory (ROM). As is well knownin the art, ROM acts to transfer data and instructions uni-directionallyto the CPU and RAM is used typically to transfer data and instructionsin a bi-directional manner. Both of these types of memories may includeany suitable of the computer-readable media described below. A fixeddisk 926 is also coupled bi-directionally to CPU 922; it providesadditional data storage capacity and may also include any of thecomputer-readable media described below. Fixed disk 926 may be used tostore programs, data and the like and is typically a secondary storagemedium (such as a hard disk) that is slower than primary storage. Itwill be appreciated that the information retained within fixed disk 926,may, in appropriate cases, be incorporated in standard fashion asvirtual memory in memory 924. Removable disk 914 may take the form ofany of the computer-readable media described below.

CPU 922 is also coupled to a variety of input/output devices such asdisplay 904, keyboard 910, mouse 912 and speakers 930. In general, aninput/output device may be any of: video displays, track balls, mice,keyboards, microphones, touch-sensitive displays, transducer cardreaders, magnetic or paper tape readers, tablets, styluses, voice orhandwriting recognizers, biometrics readers, or other computers. CPU 922optionally may be coupled to another computer or telecommunicationsnetwork using network interface 940. With such a network interface, itis contemplated that the CPU might receive information from the network,or might output information to the network in the course of performingthe above-described method steps. Furthermore, method embodiments of thepresent invention may execute solely upon CPU 922 or may execute over anetwork such as the Internet in conjunction with a remote CPU thatshares a portion of the processing.

Although illustrative embodiments and applications of this invention areshown and described herein, many variations and modifications arepossible which remain within the concept, scope, and spirit of theinvention, and these variations would become clear to those of ordinaryskill in the art after perusal of this application. Accordingly, theembodiments described are to be considered as illustrative and notrestrictive, and the invention is not to be limited to the details givenherein, but may be modified within the scope and equivalents of theappended claims.

We claim:
 1. A method of securing an app for execution on a device usingan app security program, the method comprising: generating Java classfiles for the app security program, said generating dictated by aplurality of app security policies separate from the app securityprogram and located in a plurality of policy gates, each policy gateincluding at least one app security policy, the plurality of policygates managed by a policy gate manager, wherein said policy gate managerinforms each policy gate of each checkpoint that occurs during anexecution lifecycle of the security-wrapped app and wherein each policygate calls a function in response to the checkpoint; replacing Javaclass files for the app with the Java class files for the app securityprogram, wherein the Java class files for the app that are beingreplaced function as a proxy between the app and a device operatingsystem; creating a security-wrapped app upon completion of saidreplacing of Java class files for the app; preparing thesecurity-wrapped app for execution on the device; and re-signing thesecurity-wrapped app with a new key.
 2. The method of claim 1, wherein anew app security policy is added to an existing policy gate in theplurality of policy gates.
 3. The method of claim 1, wherein a newpolicy gate is added to the plurality of policy gates in order to storea new app security policy.
 4. The method of claim 1, wherein the appsecurity policies are not hard-coded in the app security program suchthat the app security program does not include details and specificsregarding any app security policy.
 5. The method of claim 1, whereineach app security policy in a policy gate includes an underlyingcommonality with all other app security policies in the same policygate.
 6. A system for securing an app for execution on a device using anapp security program, the system comprising: memory storing the appsecurity program; and a processor configured to: generate Java classfiles for the app security program, said generating dictated by aplurality of app security policies separate from the app securityprogram and located in a plurality of policy gates, each policy gateincluding at least one app security policy, the plurality of policygates managed by a policy gate manager, wherein said policy gate managerinforms each policy gate of each checkpoint that occurs during anexecution lifecycle of the security-wrapped app and wherein each policygate calls a function in response to the checkpoint; replace Java classfiles for the app with the Java class files for the app securityprogram, wherein the Java class files for the app that are beingreplaced function as a proxy between the app and a device operatingsystem; create a security-wrapped app upon completion of said replacingof Java class files for the app; prepare the security-wrapped app forexecution on the device; and re-sign the security-wrapped app with a newkey.
 7. The system of claim 6, wherein a new app security policy isadded to an existing policy gate in the plurality of policy gates. 8.The system of claim 6, wherein a new policy gate is added to theplurality of policy gates in order to store a new app security policy.9. The system of claim 6, wherein the app security policies are nothard-coded in the app security program such that the app securityprogram does not include details and specifics regarding any appsecurity policy.
 10. The system of claim 6, wherein each app securitypolicy in a policy gate includes an underlying commonality with allother app security policies in the same policy gate.
 11. Anon-transitory computer readable medium including instructions for:generating Java class files for the app security program, saidgenerating dictated by a plurality of app security policies separatefrom the app security program and located in a plurality of policygates, each policy gate including at least one app security policy, theplurality of policy gates managed by a policy gate manager, wherein saidpolicy gate manager informs each policy gate of each checkpoint thatoccurs during an execution lifecycle of the security-wrapped app andwherein each policy gate calls a function in response to the checkpoint;replacing Java class files for the app with the Java class files for theapp security program, wherein the Java class files for the app that arebeing replaced function as a proxy between the app and a deviceoperating system; creating a security-wrapped app upon completion ofsaid replacing of Java class files for the app; preparing thesecurity-wrapped app for execution on the device; and re-signing thesecurity-wrapped app with a new key.
 12. The non-transitory computerreadable medium of claim 11, wherein a new app security policy is addedto an existing policy gate in the plurality of policy gates.
 13. Thenon-transitory computer readable medium of claim 11, wherein a newpolicy gate is added to the plurality of policy gates in order to storea new app security policy.
 14. The non-transitory computer readablemedium of claim 11, wherein the app security policies are not hard-codedin the app security program such that the app security program does notinclude details and specifics regarding any app security policy.
 15. Thenon-transitory computer readable medium of claim 11, wherein each appsecurity policy in a policy gate includes an underlying commonality withall other app security policies in the same policy gate.